perm filename DIAL78.PUB[DIA,JMC]3 blob
sn#484852 filedate 1979-10-28 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00022 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 .device xgp sides←1
C00005 00003 .onecol << cover >>
C00006 00004 .next page << title >>
C00009 00005 .insert contents
C00015 00006 .app Original Dialnet Proposal
C00022 00007 .s Scenario
C00028 00008 .s Protocols
C00032 00009 .s Research Issues
C00035 00010 .app Basic line protocol
C00051 00011 .skip 200 cb Packet Format
C00064 00012 .title area diag lines 30 to 53 chars 15 to 80
C00076 00013 .cb The DATA Command%1
C00098 00014 .app Mail protocol
C00103 00015 .s Syntax
C00108 00016 .s Goals and Non-goals
C00110 00017 .s Mail Fields
C00113 00018 .s Mail Commands
C00118 00019 .app "Personnel"
C00127 00020 .app Facilities
C00132 00021 .app Current Support
C00134 00022 . << budget >>
C00138 ENDMK
C⊗;
.device xgp; sides←1;
.require "basker.pub[sub,sys]" source;
.font 4 "gacb25"; font 5 "sup";
.FONT 6 "NGR20";
.font 7 "metlb";
.font 8 "ms25";
.font 9 "sail25";
.font A "sign57"
.FONT B "FIX25";
.require "twocol.pub[sub,sys]" source;
.
.COUNT SECTION
.MACRO S(NAME) ⊂ SECNAME←SSNAME←NULL;
.BEGIN
.skip (if lines<8 then 100 else 1);
.NEXT SECTION; TURN ON "#{←"
.NOJUST; SELECT 3
←{SECTION!}.##NAME
.SELECT 1;
.SEND CONTENTS ⊂ SKIP
∩∩6:{SECTION!}.##NAME→##{PAGE!}
. ⊃
.END ⊃
.
.COUNT appendix PRINTING "A";
.MACRO APP(NAME) ⊂ secname←ssname←null;
.BEGIN next page;
.NEXT APPENDIX; TURN ON "#{←"
.fill adjust; preface 0; SELECT 3
←Appendix {APPENDIX!}
←NAME
.SELECT 1;
.secname←"name";
.IF APPENDIX=1 THEN BEGIN
. SEND CONTENTS ⊂ SKIP
∩∩6:←%3Appendices%1
. ⊃
. END
.SEND CONTENTS ⊂ SKIP
∩∩3:{APPENDIX!}.##NAME→##{PAGE!}
. ⊃
.END ⊃
.
.every heading(,,);
.turn on "#←";
.onecol << cover >>
.group skip 7;
.begin center select A;
DIALNET
%7A Computer Communication Study
%3proposal submitted to
.select 7;
National Science Foundation
.select 3;
Washington, D.C. 20550
by
Computer Science Department
%7Stanford University
%3Stanford, California 94305
%7August 1978
.end
.next page; << title >>
.BEGIN NOFILL; PREFACE 0; INDENT 0
.TABS 35; turn on "⊗" for "%";
.TURN ON "\↓_"
.AT "≤≤" TXT "≥" ⊂ }↓_⊗9TXT⊗*_↓{ ⊃
.SELECT 1
.ONCE CENTER; SELECT 3
Research Proposal Submitted to the National Science Foundation
.SKIP 2
.select 1
Proposed Amount ≤≤$136,055≥ Proposed Effective Date ≤≤1 Jan. 1979≥ Proposed Duration ≤≤2 years≥
.SKIP 1
Title ≤≤Dialnet: a Computer Communication Study≥
.skip 1
Principal Investigator:\Submitting Institution:
≤≤Professor John McCarthy≥\ ≤≤Stanford University≥
Soc. Sec. No. ≤≤558-30-4793≥\ Department ≤≤Computer Science Department≥
\ Branch ≤≤School of Humanities and Sciences≥
.skip 4
Make grant to ≤≤ Leland Stanford Junior University ≥
.skip 5
Endorsements:
.tabs 10,35,60
.SKIP 1
\Principal Investigator\Department Head\Administrative Official
.PREFACE 1
Name\≤≤John McCarthy ≥\≤≤Edward A. Feigenbaum ≥\≤≤ ≥
.SKIP 1
Signature\≤≤ ≥\≤≤ ≥\≤≤ ≥
Title\≤≤ Professor ≥\≤≤Professor & Chairman ≥\≤≤ ≥
Telephone\≤≤(415) 497-4430 ≥\≤≤(415) 497-4878 ≥\≤≤ ≥
Date\≤≤ ≥\≤≤ ≥\≤≤ ≥
.END
.insert contents
.EVERY HEADING(%3{SECNAME},{SSNAME},{PAGE!});
.portion current
.place text
.page←0;
.twocol
.s Current Proposal
The aim of the project is the same as that of our previous
proposal a copy of which is included as appendix A.
We have generally followed the approach laid out there, though
specific plans have been altered based on experience.
Up to July 1978, one year into the grant period, the following had
been accomplished:
1. We have conferred with the following individuals and groups on our
plans about the form the protocols should take:
.begin crbreak; preface 0; nojust indent 2,12;
Vint Cerf, Defense Advanced Research Projects Agency
Sandy Fraser, et al, Bell Telephone Laboratories
Chris Ryland, Columbia University
Stu Wecker, et al, Digital Equipment Corporation
Michael Blasgen, IBM
David Moon, Ken Pogran, MIT
Glenn Richart, National Institutes of Health
Geoff Goodfellow, SRI International
.end
We believe we can satisfy all reasonable requirements if not all
reasonable tastes.
2. The following protocols exist in draft form and are included as
appendices B thru D of this proposal:
.begin nofill
B. Basic line protocol
C. File transfer protocol
D. Mail protocol (preliminary)
.end continue
A virtual terminal protocol will be forthcoming shortly.
3. Modems have been acquired and installed at the Stanford Artificial
Intelligence Laboratory and at the Stanford Low-Overhead Time-sharing
System.
We have chosen the Bell System 1200-1200 full duplex protocol for
the modems and have purchased Vadic modems meeting this standard.
4. The basic line transmission protocols have been programmed at SAIL and
revised several times in the light of that experience. Work has started
on the line transmission protocol at LOTS. We hope to have experimental
mail and virtual terminal protocols running and available for users by
the end of the summer.
The biggest problem encountered so far is that some operating systems
are unable to sustain the 1200 baud transmission rate without buffer
overflow. Other systems do not have this problem, but are too "helpful"
in that they insert spurious bytes in the data stream to warn about
a possible buffer overflow and in the process confuse any line protocol
negotiations going on. Of course, Dialnet recovers from this condition properly,
but not without data bandwidth being lost unnecessarily.
There are at least two ways around these problems: to modify the operating
systems or to develop a microprocessor front end.
The latter is somewhat more general and also offers the possibility of
putting most of the overhead of the line protocol in the front end.
Most of our early work has been on the former approach, but in the
next period we plan to pursue the latter.
Toward this end, we have included in the budget funds for four microprocessor
controlled modems.
In the period of this proposal we plan to refine and extend the basic
communication protocols and invite a number of new sites to join in
experimental implementations.
Assuming general acceptance of the experimental network, we shall endeavor
to get the protocols adopted as a national standard.
.app Original Dialnet Proposal
.section←0;
.macro appskip ⊂next page⊃;
.macro sskip ⊂skip (if lines<15 then 200 else 1)⊃;
.MACRO S(NAME) ⊂ SSNAME←NULL;
.BEGIN sskip;
. NEXT SECTION; TURN ON "{←"
. fill NOJUST; SELECT 3
←{SECTION!}. NAME
. SELECT 1; SSNAME←"NAME"
.END fill adjust ⊃
.
.s Purpose
This is a request for a grant to support an eighteen
month study and experimental implementation
of protocols that would permit ARPAnet-like facilities to
be provided to any time-sharing computer system that implemented them
and equipped itself with telephone dialing equipment and modems.
We call the system Dialnet by analogy, but unlike the ARPAnet, it
requires no administrator to "admit" new members.
The ARPAnet connects several hundred computer facilities
and allows users of one system to log in
on others, allows transmission of messages between users
of different computers, and allows the transfer of files between
computers. More generally, it allows interaction among programs in
different computers.
These facilities have proven valuable in permitting
collaboration between computer scientists at different sites and in
permitting nationwide access to unique facilities such as the MACSYMA
system for computing with algebraic and analytic expressions at
M.I.T. It permits a new form of publication in which documents are
kept in the computer, are continuously updatable, are immediately
accessible throughout the country, and in which comments from readers
are accessible to other readers.
The usefulness of the ARPAnet has prompted many non-defense
installations to try to connect to it, and in some cases this has
been possible, but in other cases the institutional and financial
obstacles have been insuperable. The main financial obstacles are
the need for a dedicated computer called an IMP costing about $80,000
at each site and the need for dedicated communication lines rented by
DoD at great expense from the telephone companies. Other networks
have been started, but they all have problems of expense and %2also
of deciding who should be on them%1. Some facilities have gone to
the expense of joining more than one network.
We propose to design protocols that can be implemented at any
time-shared computer installation without joining any formal network.
The hardware cost will be from $1000 to $5000 depending on how difficult
it is to connect devices to the computer. There will be
programs to operate a telephone dialer (rented from
the telephone company) and to transmit signals and information according
to the protocols. Any installation implementing the protocols will
be able to communicate with any other. The only disadvantage compared
with the ARPAnet will be lower speed and higher cost when the volume
of information transferred is very high.
Like ARPAnet, Dialnet will be most useful to %2full
time-sharing systems%1. In such systems, each user has named disk
files than are kept in the system even when he is absent (and
therefore remotely accessible), and new files can be created by file
transfer from other machines and on receipt of messages. The
usefulness of the message facilities normally requires that users
habitually log in each working day and are most beneficial when users
have individual display terminals in their offices. Further benefits
accrue when reports are normally prepared at terminals and when
secretaries use terminals for letters and messages. However, many
less advanced installations have found the ARPAnet useful and more
and more systems are acquiring economical full time-sharing
capability.
While we expect that the first users of Dialnet will be
regular computer users, the corresponding ARPAnet facilities have
been used by non computer people, Dialnet protocols will not require
ability to program, and we expect increasing use by others as
terminals become more widespread.
In order to make the picture more concrete, here is a
scenario of the use of the system.
.s Scenario
.macro bc ⊂ begin preface 0;nojust; select 4; indent 2,2; ⊃;
.macro econt ⊂ end continue ⊃
A user named Smith types on his terminal
.bc
mail Organik
.break
Do you have any active work there on human red cell carbonic
anhydrase B?
.end
The system looks up Organik in Smith's correspondent file and
discovers that his computer pseudonym is "NAT" at a computer called UTEX-CHEM1
that is reached at 512 471-3221 via a 1200/150 baud asychronous
modem. It selects an outgoing line with a matching modem, dials the
number and attempts to transmit the message. If the transmitting
computer cannot elicit a response from the desired recipient, it
informs the user that it will try again later and send him a message
when the transmission has succeeded. If the user's correspondent
file did not contain the telepone number and modem characteristics,
the user would have to supply them.
The identity and location of the sender and date and time of the message
are automatically placed at the front of the message.
At the receiving end, if the addressee is logged in on the computer, he
is immediately informed that mail has arrived and from whom. If not
logged in, he will receive the message the next time he logs in. In
either case, he can use the same facility to respond:
.bc
mail Smith
David Piranha (DAVE@UTEX-CHEM3) has a student working on inhibition
by anions of anhydrase B.
.end
Following up on this lead, the user types
.bc
link dave@utex-chem3
.end
A connection is made to the specified computer and, if DAVE is logged in,
he immediately receives a message saying
.bc
** Link request from Smith @SUα-CHEM7 **
.end continue
He could then type "%4link%*" and have his keyboard
and display effectively linked to those of the caller, permitting a
conversation.
Let us suppose, however, that DAVE is not logged in and the caller
is so informed. He then types
.bc
locate dave@utex-chem3
.econt
which obtains the following information from the specified computer:
.bc
David Piranha last logged out at 23:47 on 9 May 1976. Plan:
I will be out of touch May 10 through 16. I plan to visit Martin Shumway
at the University of Utah on May 17 and should return by May 18.
Will check mail from Utah.
.end
Noting that the current date is May 14, so that there is no point in
getting the message there quickly, Smith types
.bc
night mail dave@utex-chem3
.break
I am interested in your work on anhydrase B. If possible, give pointers
to online documentation, else give me a call at 415 497-4430 (Stanford)
or 415 321-7580 (home).
.econt
The "night mail" command causes the message transmission to be deferred until
inexpensive nighttime telephone rates are in force.
Additional capabilities of the Dialnet system can be used to follow up on the
above inquiry, as follows.
.begin indent 0,2; nojust
.at "⊗" ⊂ "%8α⊗%*" ⊃;
⊗ The ability to access remote text files will be provided (with permission
of the owners required, of course). This interactive reading facility will
include the addition of "footnotes" to various parts of the text. These
footnotes may be declared private (i.e. belonging to the reader) or public
(available to the author and possibly others).
⊗ It will be possible to run programs on a remote computer, permitting
experiments with programs developed in other places. This facility
will permit the sharing of unique specialized capabilities over
a geographically distributed population.
⊗ File transfers will be permitted, with suitable error detection and
correction features, to permit sharing of data. The communication protocol
should be able to adapt to a wide range of noise conditions on phone lines.
.end
.s Protocols
In order to make these facilities available, suitable protocols
must be designed, and in the course of this, a number of technical
problems have to be solved. Besides the protocols themselves, which
are communication procedures and data structures, there will be a recommended set
of terminal-level commands with syntax prompting and standard error
messages.
We believe that we have the experience to produce a set of workable
protocols, and that it is better to start with an implementation than
to standardize something that doesn't exist. The latter procedure in
recent years has led to gold-plating the requirements to the extent
that the standard is not implementable.
We propose to devise suitable protocols, test them at a few sites, publish
them, and attempt to convince other installations to implement them.
Almost certainly, initial experience will produce a requirement for
changes, and standardization committees will be formed and set to work. A
likely forum for a standardization effort would be through the ACM to the
American National Standards Committee.
We propose to allow interaction with ARPAnet sites via TIPs and
propose to discuss with ARPA and DCA whether this will be allowed.
The most general use of Dialnet involves a program in one
computer "waking up" and interacting with a program in
another machine. Dialnet protocols will handle human
messages as a subcase of this, taking into account the fact
that the subcase will have the most application for a long time
to come. Messages about where to deliver a message
sent by one time-sharing system to another will be handled as a
special sort of message that one program may send another in cases
where the two programs are not written together, but each must
know a certain "public" language. Thus we will attempt to make
a general format for requests, questions, and assertions suitable
for communication between computer programs. We will study how
to make this mesh with communication between computer programs
and people.
.s Research Issues
There are many research issues, and we don't expect to settle
all of them in the time and with the resources requested in this proposal.
Since we expect many of the issues will be clarified by the initial
implementation, we will concentrate on getting a reasonable first
implementation into experimental use.
Here are some of the issues we will study:
1. What error correction facilities are required to make up for
the deficiencies of telephone lines?
2. What is the minimal necessary burden on the time-sharing
computers carrying out the communication? What is the trade-off
between buffer size and compute time?
3. Can dial-up telephone communication rates meet most of the
needs for communication between computers belonging to different
research organizations?
4. What is the best way to handle the fact that different modem
speeds have different prices? Should one strive for a standard
speed or can a wide variety be easily accomodated?
5. How will the improved communication affect research? Since
changes will be slow, how can we tell as early as possible
what the effects will be?
6. What style of interaction is convenient for both experienced
and inexperienced users? How can communication programs be
made self-teaching without being cumbersome?
.app Basic line protocol
.begin center select 2;
by Mark Crispin
.end
.S Conventions
All numbers without an explicit base specified (i.e., octal or decimal)
should be interpreted as octal unless the number is immediately followed
by a dot, in which case it is decimal.
All three-digit octal numbers should be interpreted as representing an
8.-bit byte, with bits right-justified within the number (ie, from 000 to
377). Bytes are expressed in the form as returned by the modem (ie, lsb
first in the data stream).
All six-digit octal numbers should be interpreted as representing a
16.-bit double-byte, with bits right-justified within the number (ie, from
000000 to 177777). Double-bytes are expressed in the form returned by the
modem (ie, low order byte and lsb first); ie, 010041 is transmitted as
041 020.
.S Preface
%2←"Aren't you glad you use Dialnet? Don't you wish everybody did?"%1
%2Dialnet%1 provides a capability for geographically separated computers,
called %2hosts%1, to communicate with each other. The host computers
typically differ from one another in type, speed, word length, operating
system, etc. Each computer utilizes %2Dialnet%1 via ordinary phone lines
and special modems.
As in many other data communication schemes, a layered approach has been
selected in the design of the Dialnet protocols. Each layer sees the
immediate lower layer as a "black box" and need not be concerned about its
internal structure. The lowest layer is the line protocol of the
modems, which transfers data bytes over the phone lines and does necessary
byte framing, but otherwise has no error correction facilities. At this
writing, the modem type used are VADIC VA3405 1200/1200 baud full duplex
asyncronous modems.
Next is the %2host-host%1 layer, which breaks the data stream into chunks,
or %2packets%1. Each packet is checksummed and sequenced, so that
retransmission can be done on a packet whose previous transmission was
corrupted in some way. Many systems may want to implement this layer in
their operating system, so all %2Dialnet%1 user programs will behave at
this level in the same manner.
Finally comes the user-level protocols. This includes file transfer,
mail, linking, telnetting, etc. These are user-level programs, and %2Dialnet%1
has been designed with enough flexibility to allow for users to create
private protocols of their own.
Questions concerning %2Dialnet%1 protocols should be addressed to:
.SKIP
.BEGIN NOFILL
%2←Mark Crispin
←Artificial Intelligence Laboratory
←Stanford, California 94305
.SKIP
←Phone: (415) 491-4712
←ARPAnet: MRC@SU-AI%1
.END
Copies of all correspondence should be sent to John McCarthy and Les
Earnest at the above US mail address or via ARPAnet mail to JMC@SU-AI and
LES@SU-AI.
It is the author's intent that these protocols are both simple in their
implementation and powerful in their operation. Certainly a major design
consideration was to design protocols that ordinary mortals could
implement on their systems.
.S Host-Host Protocol
All data is sent in the form of packets, which contain a %2packet
header%1, optional %2data%1, and a %2packet trailer%1. The packet header
serves to identify the type of packet, the size of the data area and
provides information necessary for data flow and error correction. The
packet trailer provides a checksum for the packet. Packets are framed at
each end with a %2start of packet%1 and an %2end of packet%1 marker.
The bytes which indicate start of packet are called SOP, and consist of
ASCII DLE (220) followed by STX (202); similarly, the bytes which indicate
end of packet are called EOP, and are ASCII DLE followed by ETX (203).
Note that the 200 bit is %2on%1 in DLE, STX, and ETX. If a 220 byte is to
be sent, it is quoted by being sent twice. DLE followed by anything other
than STX, ETX, or DLE is currently undefined; any such combination when
received should be discarded. 020, 002, and 003 are %2not%1 considered to
be DLE, STX, and ETX.
All packets have a packet number, which for most packets starts at 001 and
is incremented with each packet sent. The packet number wraps around to
001 from 377. Up to two (the default window size) packets may be sent
before an acknowledgement is received for (at least) the first packet.
The window begins with the first unacknowledged packet; therefore the
window size is an allocation which is used up as packets are sent and is
given back as packets are acknowledged.
Some packets (ie, NOP, NAK, and ERR) have a packet number of 000. These
packets do not count against the window, and are not remembered for
retransmission after they are sent. Therefore they are lost if an error
occurs while they are being transmitted. This is because what information
they convey is generally timing-critical; if the packet was lost nothing
would be gained by sending it again.
If the sender intends to temporarily "go idle", it should send a NOP,
repeated every five seconds or so. This assures the receiver that the
sender is still up, and serves to inform the receiver if any of its
pending packets were missed. However, if the sender has packets waiting
to be acknowledged, it should retransmit the last packet on the
acknowledgement pending list. This is to avoid a possible deadlock
which occurs when the last packet before the sending goes idle is lost.
A properly received packet with a non-zero packet number must be
acknowledged for the sender to know that the receiver successfully
received the packet and to release that packet from the window. Each
packet has an acknowledgement byte which is used for this purpose. This
byte in a packet sent by the receiver contains the number of the highest
successfully received packet. Acknowledging a packet implies
acknowledging all unacknowledged packets with lower packet numbers,
therefore a successfully received packet can merely set the
acknowledgement byte for the next packet to be sent without actually
forcing a packet to be sent.
Packets must be received in sequence, with the exception of packets with
packet number 000 (see above). If the receiver receives a packet it has
already acknowledged it should discard it. Packets which have a sequence
number higher than the expected packet and packets with incorrect checksum
should be discarded, and a NAK sent for the expected packet. In the
event of a framing error, the receiver should discard all input until an
SOP is encountered in the input stream. If a packet is discarded for
being out of sequence, its acknowledgement byte should still be used,
otherwise an acknowledgement may be unnecessarily missed.
In %2Dialnet%1, the window is %2optional%1; in particular, an
implementation which uses the window should not get upset because the
foreign host disobeys it (it can of course neglect to acknowledge packets
which cause data overruns and force them to be re-sent). However, any
implementation which is trying to be reasonably efficient should do
something about handling windows and telling the foreign host what sort of
window size it can live with.
There is no official timeout for deciding whether a host is still alive
or whether the phone connection is poor enough to be unusable. Each
implementor must decide these for him/herself.
The packet checksum algorithm used is the result of a conversation with
Knuth. The checksum is 16. bits long and all of the packet header
variables and the entire data area. It does NOT include the packet
trailer or the SOP/EOP packet framing codes. Note that framing checks
happen %2before%1 the checksum check.
The algorithm is: (all numbers should be read as octal)
.skip;
.BEGIN NOjust INDENT 2,10; crbreak; preface 0;
checksum := 1;
while newchar do checksum := (checksum * 013215 + newchar) & 177777;
.END
In PDP-10 assembly code, this would be:
.SKIP
.BEGIN NOjust; crbreak; preface 0; select B;
; CHKBYT adds a byte to the checksum in SUM.
; At the beginning of each packet SUM is
; initialized to 1.
; Call: MOVE CHR,<byte from data stream>
; PUSHJ P,CHKBYT
; <return>
CHKBYT: IMULI SUM,013215
ADDI SUM,(CHR)
ANDI SUM,177777
POPJ P,
.END
There is always at least one word in the data part of the packet. The
data part size refers to the number of %2additional%1 words in the data
part. Hence the data part can be %2from 1 to 256%1 data bytes long.
This means that the "data size" field in the packet header is actually
%2one less%1 than the actual data size.
The motivation for this is that a power of two is a convenient unit of
storage for many systems. In addition, many implementations will find it
convenient to pack four data bytes in a single storage word. With framing
and DLE doubling stripped, this means that the packet header will be
exactly one storage word, and the data part will begin on a storage word
boundary. In addition, the data part of a maximum-size packet will also
end on a storage word. This is significant for many systems in terms of
buffering; whether a byte-by-byte copy must be done or a faster word
transfer. The PDP-10 implementation at Stanford exploits this; an IBM-style
machine can derive similar benefit.
In the CLS, NAK, EOF, and INT op-codes the data byte is meaningless and
should be ignored, however, it still must be present. Additionally,
this byte should always be zero, to allow these op codes to have a
meaningful data part in a future revision of the protocol.
There are no restrictions on the size or content of the data part of a
NOP packet, except the packet structure restriction that 1≤size≤256.
Since, however, the data is ignored by the receiver, a NOP packet would
generally have a one-byte data part, although some systems might want
to pad to 4 data bytes (note that this means the size field in the packet
header is 3!) to keep things on word boundaries.
.skip 200; cb Packet Format
.BEGIN center; select b;
____________________________________
| |
| 2 bytes SOP framing mark |
| |
|==================================|
| Channel # | Op Code |
| (4 bits) | (4 bits) |
|________________|_________________|
| |
| 1 byte Packet number |
|__________________________________|
| |
| 1 byte Acknowledgement |
|__________________________________|
| |
| 1 byte Data size |
|==================================|
| |
| 1 byte Data word |
|__________________________________|
| |
| (specified |
| by data Additional data bytes |
| size byte) |
| |
|==================================|
| |
| 2 bytes Packet checksum |
| |
|==================================|
| |
| 2 bytes EOP framing mark |
| |
|__________________________________|
.END
.skip; cb Host-Host Op-Codes
In the descriptions below, certain arguments are passed along with the
commands. These arguments are listed in the order in which they occur,
along with their byte size. They all occur in the DATA field of the
packet.
000 NOP (No-op)
This op code is a no-operation and should be ignored by the receiver
except that the packet still has to be acknowledged. It is used to
acknowledge a packet without doing anything else.
.IF LINES<10 THEN skip 200;
001 RPC (Request Process Connection)
.BEGIN INDENT 2,10; NOjust; preface 0; crbreak;
(optional) 8 bytes of process ID
(optional) 1 byte of initial window size
.END
This is the establish connection op code. It serves a dual purpose;
to request establishing a connection, and to confirm establishing a
connection. In the first case, the data area contains an 8.-byte %2process
ID%1, which is a handle to the remote process the sender wishes to connect
to. In the latter case, no process ID is specified. A single byte
may follow the process ID to specify an initial window size.
.IF LINES<10 THEN skip 200;
002 CLS (Close Connection)
This is the terminate connection op code. It may either terminate
an existing connection or abort a request for one.
.IF LINES<10 THEN skip 200;
003 WIN (set WINdow size)
.BREAK
.BEGIN INDENT 2 NOFILL
1 byte of window size
.END
This op code sets the input window size; ie, it suggests to the receiver
how many packets it may send before waiting for an acknowledgement. The
minimum (and default) window size is 2 packets. The absolute maximum
window is 127.; however, many systems may want to set a smaller maximum
window. At Stanford, the system maximum is 16. packets.
.IF LINES<10 THEN skip 200;
004 MSG (MeSsaGe)
.BREAK
.BEGIN INDENT 2; NOFILL
0 to 256. bytes of data
.END
This is the data transmission op code. The contents of the data
part are passed to the tertiary process.
.IF LINES<10 THEN skip 200;
005 NAK (Negative AcKnowledgment)
This op code requests that the receiver retransmit all unacknowledged
packets that it sent.
.IF LINES<10 THEN skip 200;
006 EOF (End Of File)
This op code is used to raise an "end of file" condition on a particular
channel to indicate the end of a data stream.
.IF LINES<10 THEN skip 200;
007 INT (Interrupt)
This op code is used to raise an "interrupt" condition on a particular
channel. It is intended that a user process be informed of the interrupt
twice; when it is received, and when it occurs in the data stream (the
latter is to indicate the end of the "interrupt" condition).
.IF LINES<10 THEN skip 200;
010 ERR (Error)
.BREAK
.BEGIN INDENT 2; NOFILL
0 to 256. bytes of ASCII error text
.END
This op code is used to send a protocol error warning. It is intended that
a receiver of such a warning output the contents of the data part of the
message (which should be an ASCII string) on a logging terminal so that
the support staff can determine the cause of the problem and take corrective
action. This op code should be used judiciously, since needless usage would
only defeat its purpose.
.cb Connections%1
In the discussion below, U refers to the process which initially provoked
the connection or %2user%1, S refers to the the process passively waiting
for a connection or %2server%1.
Channel 0 is to be used for ICP.
Following the establishment of a dialup connection, U should send a few
NOP's to S to avoid possible problems with dropped bytes while connecting.
U must know the process ID of the S it wants to connect to. As far as
Dialnet is concerned, process ID's are arbitrary ASCII strings. However,
conventions have been established as noted elsewhere.
U sends an RPC with the process ID at S it wants to connect to. S may
have been waiting for a connection, or perhaps was created by S's host as
a result of the RPC. If S does not exist or S's host is unable or
unwilling to make the connection at the present time, S's host should
return a CLS to refuse the connection.
Otherwise, S accepts the connection by sending an RPC back to U, with a
null process ID. The connection has now been established, and the process
ID is no longer used by the host-host protocol. The two processes may now
pass data back and forth using the various Host-Host op codes.
When a host wishes to terminate a connection, it sends a CLS. Once a CLS
has been sent, no further MSG's may be sent and any MSG sent should be
replied to with an ERR. Of course, a new connection may be established
with RPC. Breaking the phone connection implies terminating the
connection.
When a connection is terminated, the recepient of the CLS should send a
CLS to confirm terminating the process.
.S Introduction to Tertiary Protocols
All protocol communication in the higher level Dialnet protocols (e.g.
MAIL, File Transfer) uses a list format for messages. Each message
therefore has the form
(<identifier> <item> ... <item>)
where the items themselves are either identifiers or have a similar
structure. The object of this scheme is to ensure flexibility.
Suppose, for example, that one of the items in a protocol message
designates a user name. Initial designs of Dialnet may allow only a
character string without parentheses like SMITH to designate the user.
Later this might be elaborated to also allow a complex designator like
(SUCCESSOR SMITH) to designate the person who has replaced SMITH in this
job assignment.
There is no present intention that the Dialnet protocols will be subject
to rapid elaboration. The present object is merely to build these
protocols so that they will not be subject to blind alleys. Therefore,
there are no fixed size fields, and item that is initially represented by
an atomic name may later be replaced by some kind of expression, and new
terms may be adjoined to lists. Thus if an item is presently denoted by a
three term list, an elaborated protocol may later call for a four item
list, but if the same initial identifier is used, it should still be
possible for a recipient to ignore the fourth item and still use the
message.
We believe that these conventions, at slight cost in initial
implementation, will make future improvements easy should they be
required.
.title area diag lines 30 to 53 chars 15 to 80;
.place text;
.app File transfer protocol
.begin center select 2;
by Ignacio Zabala
.end
The %2File Transfer Protocol%1 (FTP) provides Dialnet hosts with a set of
commands for transmission of files among them.
Because we count on quite different systems using Dialnet, it is necessary
to establish a small set of essential commands and replies that are
implemented by all of them in order to make possible the communication
between any two sites. On top of this, additional commands are defined that
enchance data transfer between two similar hosts.
FTP commands consist of standard 8-bit ASCII strings. Any number appearing
in a command will always be decimal.
The interactions between the various parties in an FTP transaction may be
best described by the following diagram:
.place diag
.BEGIN NOFILL select b;
________ ________
| | Data | |
----->|(Output)|>---------->|(Input) |>--
! | | Channel(1) | | !
! | | | | !
! | | | | !
! | | Command | | ! _____
! | Server |<==========>| User |<======>| User|
! | Process| Channel(0) | Process| ! |_____|
∧ | | | | !
______ | | | | ! ________
| File | | | Data | | --->| File |
|System|<-<|(Input) |<----------<|(Output)|<----<| System |
|______| |________| Channel(2) |________| |________|
.END
.place text;
.skip 200;
Under request from the user process, the user program establishes a
connection with the desired server. Channel 0 is employed for exchange of
commands and replies between the user and server programs. When a
connection is established, the server sends a "reply" consisting of a
greeting message (which can contain anything, such as system name, etc.).
At this point both sites must reach some agreement about the
characteristics of the flow of data between them so that the transferred
data is interpreted in the same way at both ends of the connection. This
is the purpose of the DATA command. The agreement may be renegotiated at
any time in which no data transmission is in progress. The user may then
issue service requests thru the command channel.
.skip 200;
Data is transferred on the data channels. When the server receives a
request to retrieve a file, it tries to obtain the file and, if everything
goes right, it sends a positive reply on channel 0 and starts sending the
data on channel 1. Upon receipt of the reply, the user will start taking
packets from channel 1 and will eventually store the data in its file
system. When a store or append operations are requested it is the user
program which gets the file and sends it to the server thru channel 2.
After the request, the server is listening to this channel and when the
packets arrive, it will store the data in its file system.
Data transmission is terminated by any of the following reasons:
.BEGIN indent 0,2;
- The receiver gets an end of file on that channel. This is the normal
termination for a successful data transfer.
- An interrupt has been issued on the data channel. Any data previously
received in that transmission is discarded.
- The command channel is closed. The command channel may be closed by the
server at any time, but it will typically do so only after a request from
the user who will send it when finished using the FTP service.
.END
.cb FTP Replies%1
The following pages contain a description of the commands available in the
Dialnet File Transfer Protocol and the corresponding set of replies.
It is strongly recommended that %2all%1 the commands be implemented, although
clearly not all have the same importance.
There are only four possible replies. In each of them the first item
identifies the reply. The second item is a list which contains a string
which in most cases is passed to the user without further processing. Hence,
there is a choice as to the amount of information to return in a reply.
The replies are:
.BEGIN INDENT 2,8;
%2(OK (<optional-text>))%1
.BREAK
The command has been accepted as issued and
will cause the desired effect. If the command requires two replies, this
is the primary positive reply.
%2(DONE (<optional-text>))%1
.BREAK
This is the secondary reply for a data
transfer command whose primary reply was positive. It indicates that the
data transfer is finished.
%2(BUSY (<optional-text>))%1
.BREAK
The server cannot attend the request but if
you keep trying it may eventually give you the service.
%2(FAILED (<optional-text>))%1
.BREAK
You are losing with this command. The argument will tell the reason.
.END
.cb Access Control Commands%1
The following commands specify access control identifiers. Some sites
may not require them, but if issued they should be correct. When needed
it is the responsibility of the user program to make sure that they arrive
in the correct order. Because the server has the faculty to close the
connection at any time, it may very well do so after several unsuccessful
log-in trials.
I. (USER <user-id>)
With this command the user identifies himself to the server so that it is
granted access to its file system. Some sites might require this command to be
the first command thru the connection and may even require a complete
log-in sequence with a password and/or an account number. A new USER
command may be sent at any time, in which there is no data transmission,
to change the access control and/or accounting information. Transfer
parameters are unchanged by this command.
Replies:
.BEGIN INDENT 2,8;
%2(OK)%1
.BREAK
The user has successfully logged into the foreign host. No
password is required.
%2(OK (PASSWORD?))%1
.BREAK
The <user-id> was accepted but a correct password is
required to continue the log-in process.
%2(BUSY (<reason>))%1
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN skip 200;
II. (PASSWORD <password>)
The argument is a character string specifying the user's password.
Replies:
.BEGIN INDENT 2,8;
%2(OK)%1
.BREAK
User log-in completed.
%2(OK (ACCOUNT?))%1
.BREAK
The <password> was accepted but an account specification
is required to continue the log-in process.
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN skip 200;
III. (ACCOUNT <account>)
The argument is a string identifying the user's account.
Replies:
.BEGIN INDENT 2,8;
%2(OK)%1
.BREAK
Even if the server has no accounting service this reply should be
sent in case a fixed sequence has been issued by the user.
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN skip 200;
IV. (BYE)
The user sends this message before closing the connection, to say it is
going away.
Replies:
.BEGIN INDENT 2,8;
%2(OK)%1
.END
.cb The DATA Command%1
V. (DATA <byte-size> <type> <structure>)
The systems that communicate by means of Dialnet may have different word
(byte) lengths, employ different data representations and structure their
stored data in various ways. To solve this problem we define some
standard default values of these parameters and employ the DATA command to
change them in cases in which the standards are not adequate. All users
of Dialnet must implement the defaults, that is, they must be able to send
and receive meaningful data in contiguous logical units of 8 bits, which
can be interpreted as standard ASCII characters and are always transferred
in groups delimited by end-of-file characters.
When a connection is first established, the server will assume that the
default values will be used and will be prepared to make the necessary
data conversions from his own to the default form when sending, and from
the default to its own when receiving.
Often user and server will be similar machines and converting the data to
the standard default form will be unnecessary. The DATA command allows a
user to tell which are the parameters that he wants the server to employ
on the data in order to minimize the user's data conversion effort. It
can be issued as many times as desired but not during a data transmission.
Of course, it can also be used to return to the standard default form.
All the arguments should be given, and precisely in the specified order.
They stand for:
.BEGIN INDENT 2,8;
<byte-size> is a decimal number specifying the desired logical byte size,
i.e., starting with the first bit transmitted on the data channel, every
<byte-size> bits are a complete entity. The default byte size is 8.
<type> may be:
.END
.BEGIN INDENT 4,10;nojust
ASCII Data consist of a sequence of contiguous standard 8-bit ASCII
characters. The end of a line of text is denoted by a sequence <CRLF>.
This is the default type.
EBCDIC Data consist of 8-bit EBCDIC characters. The end of a line of text
is denoted by a <NL> character.
IMAGE Data consist of a stream of contiguous bits that should be taken in
contiguous groups of size given by the value of <byte-size>. This type is
intended for efficient transmission between similar machines.
.END
.BEGIN INDENT 2,8;
<structure> may be:
.END
.BEGIN INDENT 4,10;
FILE File (no internal structure). The end of a file is marked by an
end-of-file packet.
RECORD The data is grouped in records delimited by an EOR (end of record)
marker. At the end of the file there is an end-of-file packet after the
last EOR.
.END
If a site receives and stores a file while certain parameter values are
active and is later requested to return that file using the same values,
the input and output copies should be identical. Also we must require that
any transformation suffered by a file during the process of storing it do
not affect the contents of that file if output in another form.
Replies:
.BEGIN INDENT 2,8;
%2(OK)%1
.BREAK
Good, the server agrees.
%2(BUSY (<reason>))%1
.BREAK
You are not allowed to change the transfer parameters now.
%2(FAILED (<reason>))%1
.BREAK
The server may not have implemented one or several of the
parameter values specified by the arguments, or it can accept each of them
in some combination but not the three together as required in the command
or the arguments are not in the correct order, etc.
.END
.cb FTP Service Commands%1
VI. (RETRIEVE <for-path-name>)
This command tells the server to send the file specified by
<for-path-name> to the user. Upon receiving it, the output side of the
server's program should look for this file in the server's file system.
Then it will report the result of the lookup operation (so that the user's
program can be informed) and, if successful, will start transmitting. At
the end, a report about the result of the transfer operation will also be
emitted.
Primary replies:
.BEGIN INDENT 2,8;
%2(OK (<text>))%1
.BREAK
The lookup succeeded and the server has started sending the file.
%2(BUSY (<reason>))
(FAILED (<reason>))%1
.END
Secondary replies:
.BEGIN INDENT 2,8;
%2(DONE (<text>))%1
.BREAK
The transfer is finished and the data channel closed.
%2(STOPPED (<text>))%1
.BREAK
Channel 1 was closed before an end-of-file had arrived.
The part of the file that had already been transmitted (if any) will not
be saved, i.e. the RETRIEVE command will not have any effect.
.END
.SKIP
.IF LINES<10 THEN skip 200;
VII. (STORE <for-path-name>)
The server should open a file named <for-path-name> and store in it the
data that the user will send. If a file with that name already exists at
the server site it will be overwritten, otherwise the server should create
it.
Primary replies:
.BEGIN INDENT 2,8;
%2(OK (<text>))%1
.BREAK
The file has been found or created. The server is ready to
receive the data thru channel 2.
%2(BUSY (<reason>))
(FAILED (<reason>))%1
.END
Secondary replies:
.BEGIN INDENT 2,8;
%2(DONE (<text>))%1
.BREAK
The transfer is finished (an end-of-file has been
received). The file is closed and so is data channel 2.
%2(STOPPED (<text>))%1
.BREAK
Channel 2 closed before an end-of-file arrived. The
part of the file that had already been received (if any) will not be
saved. The STORE command will not have any effect.
.END
.SKIP
.IF LINES<10 THEN skip 200;
VIII. (APPEND <for-path-name>)
This command tells the server to open the file specified by
<for-path-name> for input and append to it the data that the user will
send thru channel 2. If no file exists with that name this command will
have the effect of a STORE command.
Primary replies:
.BEGIN INDENT 2,8;
%2(OK (<text>))%1
.BREAK
The file has been found or created.
%2(BUSY (<reason>))
(FAILED (<reason>))%1
Secondary replies:
%2(DONE (<text>))%1
.BREAK
The transfer is finished (an end-of-file has
been received). The file is closed and so is data channel 2.
%2(STOPPED (<text>))%1
.BREAK
Channel 2 has been closed before an end-of-file has arrived. The part of the file
that had already been received (if any) will not be saved. The APPEND
command will not have any effect.
.END
.SKIP
.IF LINES<10 THEN skip 200;
IX. (ABORT)
This command tells the server that the file transfer requested by the
previous command has been cancelled. For that purpose an interrupt packet
is sent to the server on the data channel. Because the server was
attending that channel, it will recognize the packet, terminate any data
transmission or reception and turn its attention to the command channel.
Any data received so far will be discarded. The previous command will have
no effect on the files of either the user or the server. Had the transfer
already been completed and the data channel closed, the receiver would
have already closed the file in its file system and no abortion would be
possible.
Only file transfers can be aborted because there is no control on the
other services from the very first moment in which the corresponding
command is issued.
Replies:
.BEGIN indent 2,8;
%2(OK)
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN skip 200;
X. (RENAME <for-path-name1> TO <for-path-name2>)
The server is instructed to change the name of <for-path-name1> to
<for-path-name2>.
Replies:
.BEGIN indent 2,8;
%2(OK)
(BUSY (<reason>))
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN skip 200;
XI. (DELETE <for-path-name>)
The server is instructed to delete the file specified by <for-path-name>.
Replies:
.BEGIN indent 2,8;
%2(OK)%1
.BREAK
The file has been deleted.
%2(BUSY (<reason>))
(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN skip 200;
XI. (DIRECTORY <for-dir-name>)
This command asks the server for a list of the files in the directory
specified by <for-dir-name>. If no argument is given a list of the files
in the log-in directory should be sent. The information will be contained
in the reply (sent thru the command channel).
Replies:
.BEGIN indent 2,8;
%2(OK <file-list>)%1
.BREAK
<file-list> is the requested list of files. It should be
passed directly to the human user.
%2(FAILED (<reason>))%1
.END
.SKIP
.IF LINES<10 THEN skip 200;
XII. (STATUS)
With this command the user asks for whatever information the server may
want to send him. It may be issued at any time. The information will be
sent as a reply on channel 0 (the command channel!) and is intended
exclusively for human users.
Replies:
.BEGIN indent 2,8;
%2(OK <information-list>))%1
.BREAK
The contents of the <information-list> should be
directly sent to the human user for its interpretation. This is the only
legal reply.
.END
.S Glossary
The following terms are used in this document and are defined here to
remove ambiguity:
.BEGIN indent 2,8;
ACKNOWLEDGEMENT -- an 8.-bit quantity which specifies the packet sequence
number of the highest consecutive packet which has been successfully
received. An acknowledgement implies that all packets with lower sequence
numbers have been received as well.
BYTE -- an 8.-bit quantity. While %2Dialnet%1 transmissions are to be
considered as a bit stream, this concept is convenient to use for many
reasons.
BYTE SIZE -- this refers to the byte size of data as seen by the host
computer. All %2Dialnet%1 transmissions should be considered bit stream
transmissions sent in units of 8.-bit bytes.
CHANNEL -- an 8.-bit quantity identifying which data stream this packet
belongs to. Channels have no meaning to the host-host protocol, only to
higher level protocols. Channel 0 is the channel normally used.
CHECKSUM -- a 16.-bit quantity containing a packet checksum, used in error
detection.
CONNECTION -- a logical connection between two processes. Connections are
bidirectional.
DATA -- an arbitrary amount of data which is either used as arguments in
the Host-Host protocol or as data to be passed to a process utilizing
%2Dialnet%1.
DATA COUNT -- a 8.-bit quantity indicating how many bytes are in the data
field of the packet after the first data byte.
%2Dialnet%1 -- a communications protocol for data transmission over
standard phone lines. This term also refers informally to the set of
hosts which implement %2Dialnet%1.
EOP -- a marker used to indicate end of packet. EOP consists of ASCII DLE
(220) followed by ETX (202). It is a violation of packet framing for a
packet to end with anything other than an EOP. A packet is not completely
received until this code has been received. Note that the 200 bit must be
set for an EOP to be recognized as such.
HOST -- a system with %2Dialnet%1-compatible modems and
%2Dialnet%1-support software which knows the telephone number of at least
one other host.
HOST-HOST PROTOCOL -- The protocol which provides for compatible
communication between two processes running on (probably) dissimilar
hosts.
LINE TRANSMISSION PROTOCOL -- The protocol which provides for error free
transmission between two hosts with a common modem which use the Host-Host
protocol.
OP CODE -- a %2Dialnet%1 host-host protocol operation code.
PACKET -- a logical unit of data transmitted over a %2Dialnet%1 link. The
packet is the elementary unit of %2Dialnet%1 transmissions. A packet is
basically data with a header and trailer.
PACKET FRAMING -- a technique used in the line transmission protocol which
requires that all packets start with an SOP marker and end with an EOP
marker. A packet must be properly framed for it to be considered to have
been received correctly. Framing errors cause the packet in progress and
all succeeding data to be discarded until framing is restored.
PACKET NUMBER -- an 8.-bit quantity which uniquely identifies a packet at
a given point in time. This is used to identify packets if necessary in
error recovery. Packet numbers may be recycled after both hosts have
agreed that the packet associated with this packet number has been
correctly sent and received.
PROCESS -- an entity utilizing %2Dialnet%1. %2Dialnet%1 traffic consists
of communications between processes.
PROCESS ID -- an 8.-byte ASCII string which uniquely identifies the
process. See the ICP and higher-level protocols for process-ID
conventions.
SERVER -- the initially passive process in a connection.
SOP -- a marker used to indicate start of packet. SOP consists of ASCII
DLE (220) followed by STX (203). It is a violation of packet framing for
a packet to begin with anything other than an SOP. Any data received when
an SOP is expected should be discarded. Note that the 200 bit must be set
for an SOP to be recognized as such.
TIMEOUT -- A delay time for a specified action. If the desired action
does not occur within a specified time, a "timeout" action is taken.
USER -- the initially active process in a connection.
WINDOW -- The margin for packets vs. their acknowledgements so that
acknowledgements do not have to be completely synchronous with packets.
WINDOW SIZE -- The maximum number of unacknowledged packets which may be
pending at any time. This is similar to what the ARPAnet calls "message
allocation".
.END
.app Mail protocol
.begin center select 2
by Mark Crispin 3/27/78
.end
The host-host protocol described in Dialnet memo #2 documents a mechanism
for hosts to establish an error-free data link between two cooperating
processes. This protocol, however, is insufficient to specify
communication between dissimilar mail processes in different hosts. The
processes must have some agreement as to the format messages should be in,
and how mail addressing and delivery should be handled.
The ARPAnet implements mail as part of the file transfer protocol. This
has some advantages and disadvantages. A short-term advantage of this
form of mailing is that it is relatively simple to implement and interface
to an existing mail system if the current mail system already uses
something approaching the standard format.
In the long term, however, many problems have arisen as increasingly, more
varieties of mail formats have appeared and more hairy mail reading
programs have been written to parse these formats. It would be
short-sighted to assume that this would not happen with Dialnet mail as
well. In addition, the ARPAnet mail formats leave much to be desired.
First, they are in the format of a business memorandum, leading many to
the assumption that a business memorandum was the proper format for
message headers to take.
Second, too much flexibility was allowed in the formats of various items,
with the unfortunate result that too many esoteric varieties of mail
commands ensued, and many trivial arguments over highly esoteric matters
developed.
Dialnet mail avoids the problem with multiple formats of message headers
by eliminating them entirely. Instead, messages are sent using a mail
protocol. Each host is only required to implement what parts of the
protocol they require after a certain common minimum subset. If a host
wishes to have a message heading (as well it might, since valuable
information such as whom the message was from is contained therein), it
may generate a header in any format.
Keeping this in mind, a method of expressing such information in a clearly
unambiguous and readily machine-parsable way was sought. The LISP syntax
of S-expressions was chosen, due to its extreme versatility.
In the mail protocol, the user sends S-expressions as commands to the
server, which replies in turn using S-expressions. No actual LISP
evaluating is actually done; all that is needed is a "LISP reader" which
can recognize an S-expression and be able to distinguish the CAR and CDR
of an expression.
For those unfamiliar with LISP, a brief introduction to the syntax is on
the next page. It is not intended to be a description of LISP syntax, but
rather the "LISPese" syntax used by Dialnet mail.
.s Syntax
The mail protocol consists of an interchange of S-expressions, which are
things inside balanced parenthesis. Parenthesis are special characters in
all cases. In order for them to be included in text, they must be quoted
with a slash (/) character. Hence slash is a special character as well.
Newline is represented by an 012 byte. This is distinct from the "line
feed" character, which does not exist in the mail protocol.
The character set which is legal in the mail protocol consists of all the
printing characters in the 1968 ASCII character set including space (in
other words, the characters whose ASCII value is between 040 and 176) and
newline. In particular, rubout and the "control" characters (some of
which are used for text formatting on some systems) are not part of the
protocol and should not be used. There is no guarantee that the server
will interpret these characters in the way the user intended.
If for some reason "control" characters MUST be sent, it should be noted
that line feed must be quoted since otherwise it would be interpreted as
newline. Again, servers are under no obligation to implement "control"
characters.
There are no other special characters. In particular, whitespace and
newlines within an S-expression are treated as significant in many places.
In non-textual situations, such as delimiting between atomic values, a
single whitespace or newline is required and further whitespace/newlines
are superfluous and should be ignored. However, while mail servers should
be prepared to ignore superfluous whitespace or newlines, it is strictly
speaking a violation of protocol to send superfluous whitespace or
newlines.
Some LISP terms need to be defined for the non-LISP user to make the rest
of this document clearer. Within an S-expression, there can be atoms or
other S-expressions. An atom is an indivisible "word". The other
S-expressions are called "lists", as they are not evaluated further.
The CAR of an S-expression or list is the first atom in the list. The CDR
is what remains of the S-expresssion after the CAR has been removed.
These two terms are sometimes combined; the second element of the list is
the CAR of the CDR or the CADR; the third element is the CAR of the CDR of
the CDR or CADDR, etc.
EXAMPLES:
1. FOO is an atom
2. (FOO BAR) is a list
3. (FOO BAR GARPLY) is a list
4. (FOO BAR (BAZ GARPLY)) is a list
5. FOO is the CAR of #2, #3, and #4
6. (BAR (BAZ GARPLY)) is the CDR of #4
7. BAR is the CAR of #6
8. (BAZ GARPLY) is the CDR of #6
9. FOO/ BAR is an atom!!
.s Goals and Non-goals
The following are goals:
1. To avoid repeating the mistakes of ARPAnet mail.
2. To have a system that is simple to implement.
3. To establish strict mail formats with no ambiguity of format, to prevent the
proliferation of mail header formats which has occured in the ARPAnet.
4. To allow the mail sender complete freedom in what is included in the actual
body of the mail message.
5. To abolish mail headers as they exist in current mail systems entirely.
6. To replace the information formerly contained in the mail header with a mail
protocol negotiation.
The following are currently non-goals. It is felt that there is no
justification at the present time to consider these matters.
1. Compatability with ARPAnet mail.
2. Message security or encryption. This may happen later.
3. Explicit forwarding.
4. Detection and deletion of duplicate copies of a message or of mail loops.
.s Mail Fields
In all mail fields, it is %2strongly suggested%1 that either upper or
lower case be accepted, and that lower case be converted to upper case for
machine- reading purposes. In addition, the official case for protocol
commands is upper case; however, a server must not depend upon only
receiving upper case. A server that fails to do case-independent matching
is bound to encounter problems in interfacing with other systems.
The fields or arguments to a mail protocol command are one of the
following:
.begin indent 0,8; nojust
ADDRESS -- an atom or list which specifies a valid machine-readable mail
address on the host in question.
HOST-IDENTIFICATION -- either phone-number or a list whose CAR is
phone-number and whose CADR is host-name.
HOST-NAME -- an atom which specifies the official host name as kept on
record by the Dialnet implementors.
MESSAGE-TEXT -- a text string consisting of the actual text of the
message.
PHONE-NUMBER -- a dialup phone number in the form of a string of digits.
SUBJECT-TEXT -- an optional text string used as a one-line "topic" of the
message.
TEXT -- a data type (see SUBJECT-TEXT and MESSAGE-TEXT) which is
completely quoted. TEXT outwardly looks like a list in that there are
parentheses at each end, and parentheses and slashes must be quoted with
slash; however, whitespace and new lines are significant and are not
converted to something else by the mail process.
.end
.s Mail Commands
The commands on these pages are the more important commands of the mail
protocol which all servers are expected to implement.
For all mail commands, the reply (FAILED) is used to indicate a command
that failed due to some internal bug on the part of the server, for such
things as string space exhausted or the like. This code is NOT intended
to be used to indicate a user error.
I. (TO address)
This is the most important command in the mail protocol, and the only
required one. It specifies to whom the message is to be sent. The
address must be a legal address for the server site; ie, it must be
machine-readable as opposed to a "human" address.
Examples:
(TO MRC)
(TO Network/ Wizard)
Replies:
.begin indent 0,6; nojust
(OK) The address has been accepted. More destinations may be specified for
this message.
(OK-NO-MORE)
The address has been accepted, but no more destinations may be
specified for this message.
(UNKNOWN)
The address has been rejected; there is no known destination at this
site with that address.
(ILLEGAL) The address is in illegal format for this site.
.end
II. (FROM address host-identification)
This command specifies the origin of the message. The address must be a
legal address for the user site's mail server; ie, it must be
machine-readable. The address in this command is the default for the
SENDER and REPLY-TO addresses. It should be noted that many sites may not
wish to implement SENDER and REPLY-TO. This means that FROM is required
if any origin is specified at all, and that it should specify a reasonable
origin and reply address.
Examples:
(FROM MRC 415-497-1234)
(FROM DIALNET-HACKER (415-497-4321 SU-AI))
Replies:
.begin indent 0,6; nojust
(OK) The command was accepted. This is the only legal response.
.end
III. (SUBJECT subject-text)
This command specifies a subject text for the message. It is used to
provide a short topic for the message for the reference or filing purposes
of the eventual message reader.
Examples:
.begin indent 0,6; nojust
(SUBJECT (Suggested addition to the MAIL protocol))
(SUBJECT (In reply to your message about the MAIL protocol))
Replies:
(OK) The command was accepted. This is the only legal response.
.end
IV. (MESSAGE message-text)
This command specifies the text body of the message.
Example:
(MESSAGE (It has been suggested that the MAIL protocol be enhanced
to make the phase of the moon be a required item in all
messages. It is felt that this item is very important
and all user and server programs will be expected to
implement this by next Tuesday.
))
Replies:
.begin indent 0,6; nojust
(OK) The command was accepted. This is the only legal response.
.end
.app "Personnel"
Biography of John McCarthy
.begin nojust; indent 0,4;
BORN: September 4, 1927 in Boston, Massachusetts
EDUCATION:
B.S. (Mathematics) California Institute of Technology, 1948.
Ph.D. (Mathematics) Princeton University, 1951.
HONORS AND SOCIETIES:
American Mathematical Society,
Association for Computing Machinery,
Sigma Xi,
Sloan Fellow in Physical Science (1957-59),
ACM National Lecturer (1961),
IEEE,
A.M. Turing Award from Association for Computing Machinery (1971).
PROFESSIONAL EXPERIENCE:
Proctor Fellow, Princeton University (1950-51),
Higgins Research Instructor in Mathematics, Princeton University (1951-53),
Acting Assistant Professor of Mathematics, Stanford University (1953-55),
Assistant Professor of Mathematics, Dartmouth College (1955-58),
Assistant Professor of Communication Science, M.I.T. (1958-61),
Associate Professor of Communication Science, M.I.T. (1961-62),
Professor of Computer Science Stanford University (1962 - present).
PROFESSIONAL RESPONSIBILITIES AND SCIENTIFIC INTERESTS:
With Marvin Minsky organized and directed the Artificial
Intelligence Project at M.I.T.
Organized and directs Stanford Artificial Intelligence Project
Developed the LISP programming system for computing with
symbolic expressions, participated in the development
of the ALGOL 58 and the ALGOL 60 languages.
Present scientific work is in the fields of Artificial
Intelligence, Computation with Symbolic Expressions,
Mathematical Theory of Computation, Time-Sharing computer
systems.
PUBLICATIONS:
.count ref inline; at "⊗" ⊂next ref; ("["&ref&"] ");⊃
. at "<" ⊂"%2"⊃; at ">" ⊂"%1"⊃;
⊗"Towards a Mathematical Theory of Computation", in
<Proc. IFIP Congress 62>, North-Holland, Amsterdam, 1963.
⊗"A Basis for a Mathematical Theory of Computation",
in P. Biaffort and D. Hershberg (eds.), <Computer Programming and
Formal Systems>, North-Holland, Amsterdam, 1963.
⊗(with S. Boilen, E. Fredkin, J.C.R. Licklider)
"A Time-Sharing Debugging System for a Small Computer", <Proc.
AFIPS Conf.> (SJCC), Vol. 23, 1963.
⊗(with F. Corbato, M. Daggett) "The Linking
Segment Subprogram Language and Linking Loader Programming
Languages", <Comm. ACM>, July 1963.
⊗"Problems in the Theory of Computation", <Proc. IFIP
Congress 1965>.
⊗"Time-Sharing Computer Systems", in W. Orr (ed.),
<Conversational Computers>, Wiley, 1966.
⊗"A Formal Description of a Subset of Algol", in T.
Steele (ed.), <Formal Language Description Languages for Computer
Programming>, North-Holland, Amsterdam, 1966.
⊗"Information", <Scientific American>, September
1966.
⊗"Computer Control of a Hand and Eye", in <Proc.
Third All-Union Conference on Automatic Control (Technical
Cybernetics)>, Nauka, Moscow, 1967 (Russian).
⊗(with D. Brian, G. Feldman, and J. Allen) "THOR -- A
Display Based Time-Sharing System", <Proc. AFIPS Conf.> (FJCC), Vol.
30, Thompson, Washington, D.C., 1967.
⊗(with James Painter) "Correctness of a Compiler for
Arithmetic Expressions", Amer. Math. Soc., <Proc. Symposia in
Applied Math., Math. Aspects of Computer Science>, New York, 1967.
⊗"Programs with Common Sense", in Marvin Minsky
(ed.), <Semantic Information Processing>, MIT Press, Cambridge, 1968.
⊗(with Lester Earnest, D. Raj. Reddy, Pierre Vicens) "A
Computer with Hands, Eyes, and Ears", <Proc. AFIPS Conf.> (FJCC),
1968.
⊗(with Patrick Hayes) "Some Philosophical Problems from the
Standpoint of Artificial Intelligence", in Donald Michie (ed.),
<Machine Intelligence 4>, American Elsevier, New York, 1969.
⊗"The Home Information Terminal", <Man and Computer,
Proc. Int. Conf., Bordeaux, 1970>, S. Karger, New York, 1972.
⊗McCarthy, John, "Mechanical Servants for Mankind", <Britannica Yearbook of
Science and the Future>, 1973.
⊗McCarthy, John, Book Review: "Artificial Intelligence: A General Survey"
by Sir James Lighthill, <Artificial Intelligence>, Vol. 5, No. 3, Fall 1974.
⊗McCarthy, John, "Modeling Our Minds" <Science Year 1975>, The World Book Science
Annual, Field Enterprises Educational Corporation, Chicago, 1974.
⊗McCarthy, John, "Proposed Criterion for a Cipher to be Probable-word-proof",
<Comm. ACM>, February 1975.
⊗McCarthy, John, "An Unreasonable Book", a review of <Computer Power and
Human Reason> by Joseph Weizenbaum (W.H. Freeman and Co., San Francisco,
1976), <SIGART Newsletter> #58, June 1976.
⊗McCarthy, John, Review: <Computer Power and Human Reason>, by Joseph
Weizenbaum (W.H. Freeman and Co., San Francisco, 1976) in <Physics
Today>, 1977.
⊗McCarthy, John, "Another SAMEFRINGE", <SIGART Newsletter> No. 61, February 1977.
⊗McCarthy, John, "The Home Information Terminal", <The Grolier Encyclopedia>,
1977.
⊗McCarthy, John, M. Sato, T. Hayashi, S. Igarashi, "On the Model Theory of Knowledge",
<Proc. Int. Joint Conf. on A.I.>, August 1977.
⊗McCarthy, John, "Epistemological Problems of Artificial Intelligence",
<Proc. Int. Joint Conf. on A.I.>, August 1977.
⊗McCarthy, John, "History of LISP",
<Proc. ACM Conf. on History of Programming Languages,> 1978.
⊗McCarthy, John, "Representation of Recursive Programs in First Order Logic",
<Proc. Int. Conf. on Mathematical Studies of Information
Processing,> Kyoto Japan, 1978.
⊗McCarthy, John, "Ascribing Mental Qualities to Machines",
<Philosophical Perspectives in Artificial Intelligence,> Martin Ringle (ed.),
Humanities Press, to appear 1978.
.end
.app Facilities
The computer facilities of the Stanford Artificial Intelligence
Laboratory include the following equipment, most of it purchased with
U.S. Government research funds.
.begin "facil" indent 0,10; nojust;
Central processors: Digital Equipment Corporation KL10 and
KA10.
Primary store: 1,048k words (36 bit) of 1 to 1.6 microsecond core
(DEC and Ampex)
File store: Ampex disc file (3330-11 type), 7 spindles
(capacity: 9.1 x 10%59%* bits).
Peripherals: 4 Dectape drives, 2 mag tape drives (7 channel),
line printer, Calcomp plotter, Xerox Graphics Printer
Terminals: 58 Data Disc displays, 6 III displays, 4 IMLAC displays,
25 Datamedia displays, 5 TI terminals
Realtime processors: DEC PDP-11/45 and SPS-41 with 8k words (16 bit) of core
and 197k words of Intel MOS memory.
Communications processor: BBN TIP (Honeywell DDP-316) connected to the ARPA
Network.
Special equipment: Audio input and output systems, hand-eye equipment
(3 TV cameras, 2 arms), remote-controlled cart.
.end "facil"
.skip 10
The computer facilities of the Stanford Low Overhead Timesharing System
consist of the following.
.begin indent 0,10; nojust;
Central processor: Digital Equipment Corporation DECsystem 2050 (36 bit machine).
Primary store: 512k words (36 bit) of 1 microsecond DEC core.
File store: 3 DEC RP06 disc drives (capacity: 4.8 x 10%59%1 bits).
Peripherals: DEC 9-track tape drive, 3 Printronix line printers.
Terminals: 60+ Lear-Siegler ADM-3 and Hazeltine 1500 terminals.
.end
.app Current Support
Prof. McCarthy is currently being supported by the Advanced Research
Projects Agency under Contract MDA903-76-C-0206 (1 January 1976 - 30 Sept.
1978, $918,000/year) and by the National Science Foundation for Basic
Research in Artificial Intelligence under Grant MCS 78-00524,
July 1978 through June 1979 at $105,197.
Prof. McCarthy also oversees but receives no personal support from the
following NSF grants and contracts.
.begin indent 0,3;nojust
1. Verification Oriented Programming under Grant Number MCS76-00327, June
1976 - June 1980, $93,000/year.
2. Exploratory Study of Computer Integrated Assembly
Systems, Contract DAR78-15914, August 1978 - July 1980,
$300,000/year.
3. "A Unified Approach to Automatic Programming", Grant MCS-76-83655,
July 1977 - June 1979, $53,350/year.
4. "Verification of Operating Systems written in Concurrent Pascal",
Grant MCS 77-01194, August 1977 - July 1979, $37,000/year.
.end
. << budget >>
.onecol
.app Budget
Two years beginning 1 January 1979.
.begin "budget" nofill select 4; narrow 5;
Man 1 Jan.'79 to 1 Jan.'80 to
Months 31 Dec.'79 31 Dec.'80
A. SALARIES AND WAGES
1.Senior Personnel
Professor John McCarthy 1 - - - - - -
Principal Investigator (5α%)
Lester Earnest (10α%) 2 $4,058 $4,383
Res. Scientist & Lecturer
2..Other Personnel
a.Programmer
Mark Crispin (100α%) 14,416 15,572
b.Student Research Assistants
Acad. yr. 50α%, Sum. 100α% 7,710 8,322
c.Support Personnel
Secretary (10α%) 1,253 1,353
Electronic Technician (15α%) 2,404 2,596
______ ______
Total Salaries and Wages 29,841 32,226
B. STAFF BENEFITS 6,155 7,025
20.3α% till 8/31/79,
21.6α% till 8/31/80,
22.4α% thereafter ______ ______
C. TOTAL SALARIES, WAGES, 35,996 39,251
AND STAFF BENEFITS
D. PERMANENT EQUIPMENT
4 microprocessor-controlled modems 8,000
E. EXPENDABLE SUPPLIES 1,000 1,000
& EQUIPMENT(e.g., copying,
office supplies,postage,
freight,consulting,honoraria)
F. TRAVEL 1,200 1,200
G. PUBLICATION COSTS 500 500
H. COMPUTER COSTS - - - - - -
I. OTHER COSTS
Telephone 200 200
______ ______
J. TOTAL DIRECT COSTS (A through I) 46,896 42,151
K. INDIRECT COSTS 22,560 24,448
58α% of (J less D) ------ ------
L. TOTAL COSTS (J plus K) $69,456 $66,599
------- -------
Total Budget (two years) $136,055
.end "budget"
.SELECT 6; skip 4
The source file of this document is DIAL78.PUB[DIA,JMC]@SU-AI.
.twocol
.back